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Abstract 


An interface for specifying rigid-body motions for CFD applications is presented. This interface 
provides a means of describing a component hierarchy in a geometric configuration as well as 
motion (prescribed or six-degree-of-freedom) associated with any component. The interface cons^ s 
of a general set of datatypes, along with rules for their interaction, and design^ to be flexible 
in order to evolve as future needs dictate. The specification is currently implemented with an XML 
file format which is portable across platforms and applications. The motion specification is capable 
of describing general rigid body motions, and eliminates the need to write and compi e new code 
within the apNication software for each dynamic configuration, allowing client ^^^are to automate 
dynamic simulations. The interface is integrated with a GUI tool which allows rigid body mo ions o 
be prescribed and verified interactively, promoting access to non-expert users. Illustrative examp , 
as well as the raw XML source of the file specifications, are included. 


1 Introduction 

It is common practice in CFD applications to 
compute a parameter study using static configura- 
tions. For example, a single (usually steady-state) 
simulation can be computed for various flap de- 
flection angles, freest ream Mach numbers, and an- 
gles of attack. In this manner a matrix of static 
^^snapshots^^ of the flowfield can be easily gener- 
ated, and interrogated to discern trends. This is 
possible, in part, because the inputs required by 
a CFD flow solver to perform a static simulation 
(those controlling the choice of scheme, timestep, 
etc. aside) are usually only the geometry filename 
(typically a character string) and freestream con- 
ditions (scalars). If some means of varying these 
input parameters can be devised, powerful auto- 


*ELORET. Meiuber AIAA 
^Senior Member AIAA 

tU.S. Army AFDD (AMCOM). Senior Member AIAA 
Copyright ©2003 by the American Institute of Aero- 
nautics and Astronautics, Inc. No copyright is asserted in 
the United States under Title 17, U. S. Code. The U. S. 
Government has a royalty- free license to exercise all rights 
under the copyright claimed herein for Governmental pur- 
poses. All other rights are reserved by the copyright owner. 


mated tools for generating large ‘'databases’^ of 
static simulation results can be built (cf. Refs. [1, 
2]). When working with dynamic simulations how- 
ever, where it is desired that the geometry move 
in some manner during the computation, a simple, 
yet general, means of describing the required mo- 
tion is unavailable. Common methods of specifying 
a moving geometry for a CFD application include 
limiting the allowable motions, such as only provid- 
ing a constant rotation rate about a Cartesian axis, 
or requiring the user to prescribe the motion by 
writing code that can be called from within the ap- 
plication. The former of these is not general enough 
for complex motions, while the latter does not lend 
itself to automation, and requires an “expert user 
to implement. A method for describing geometric 
configurations and their dynamic motions which is 
general, can be automated, and is readily accessible 
to non-expert users is desired. 

Towards this end, this work presents a proto- 
col for specifying geometric hierarchies and their 
rigid-body motions. This protocol takes the form 
of a general set of datatypes and rules which can 
be implemented through any desired syntax, with 
the current choice being the Extensible Markup 
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Language (XML) [3]. This low- level XML imple- 
mentation is then ‘‘wrapped” with an Application 
Programming Interface (API). With this interface 
between the geometry motion and the application 
tools (such as the CFD flow solver), it is possible to 
build automated tools for performing dynamic sim- 
ulations, such as would be required to compute a 
matrix of dynamic stability derivatives (cf. Refs. [4- 
6]). The specification is suitable for simple ana- 
lytic prescribed motions, as well as complex N-body 
problems with collisions and controller feedback. A 
fixed specification for the geometry motion allows 
multiple application programs, such as visualiza- 
tion tools, flow solvers, and post-processing tools, 
to be built upon a common interface. The geom- 
etry motion can be stored in a single repository, 
and shared among distributed applications, which 
minimizes errors due to duplication. Efforts to ex- 
tend the specification to include geometry states 
and non-rigid bodies are underway, and will be dis- 
cussed at the end of this article. Illustrative ex- 
amples are used throughout this article to describe 
the specification, and the entire XML description 
for these examples is included in the appendixes for 
reference. 


2 Design Goals 

The collection of datatypes and standards for 
the current geometry specification, along with the 
API, file parsers, and other auxiliary packages, is 
referred to as the Geometry Manipulation Proto- 
col (GMP) (cf. Fig. 1). Reference to a protocol is 
inspired by Internet Protocols (IP). IPs are low- 
level conventions which enable data to be trans- 
ferred between machines, and higher- level applica- 
tions to be built upon a common standard. Simi- 
larly, GMP is a set of low-level conventions which 
enable geometry descriptions and manipulations to 
be shared and understood among various (higher- 
level) CFD applications and tools. Currently, the 
interface is implemented using an XML file for- 
mat along with an analytic function parser, al- 
though the interface is not specific to XML. The 
function parser will be described in Sec. 4. The 
specification is implemented in a stand-alone li- 
brarv with an ANSI-C interface. This interface 
is extended using the Simplified Wrapper Inter- 
face Generator (SWIG) [7, 8] to support all popular 
scripting languages, including Perl, Python, Java, 
Tcl, etc. GMP is currently integrated within an 



Figure 1: Schematic of GMP implementation components. 
The core is a set of datatypes and standards, which are im- 
plemented with an XML file specification. The XML file 
parser and analytic function parser provide low-level func- 
tionality. An ANSI-C API is built on top of these, and 
is extended using SWIG[8] to provide an interface for all 
common interpreted languages. High-level applications im- 
plement a customized middleware layer on top of the API 
provided by GMP. 

inviscid Cartesian moving-body flow solver [9], the 
OVERFLOW-D structured, overset, viscous, dy- 
namic flow solver [10], as well as the OVERGRID 
pre-processing Graphical User Interface (GUI) [11], 
along with several support applications. 

Two of the primary goals during the develop- 
ment of the current specification were: 1 ) that it 
easily allows higher- level application programs (or 
scripts) to modify the data for analyzing an entire 
parameter space of dynamic simulations, and 2) 
that it also enables the use of GUFs for specifying 
the motion of rigid components. In order to sat- 
isfy the first item, it was decided that only a plain 
text (human-readable) file format could be used. 
There are many schemes that could be used for 
defining a plain text specification, however for the 
current application the syntax should allow vari- 
able definitions, comments, nested structures, and 
also the ability to insert the contents of another file 
(similar to the #include mechanism of the C pro- 
gramming language). XML satisfies all these crite- 
ria, and also provides several additional desirable 
features. By implementing the rigid-body motion 
specification using XML, it is possible to leverage 
the large amount of development work dedicated 
to XML in the web and database communities. 
Public-domain and commercial software packages 
exist for parsing, validating, displaying, generating 
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databases, and many other tasks for manipulating 
XML files. XML is not only portable across plat- 
forms, it also can be “understood” by many differ- 
ent applications, from web browsers to word pro- 
cessors. An example is the color-coded XML source 
included in the appendixes, which were generated 
by a web browser. One final attractive feature of 
XML for the current application is that the hier- 
archical structures that appear in many geometric 
configurations, and also their motions, are directly 
supported by the XML language. 

The motion specification is intended to be simple 
and intuitive enough that it can be used for rela- 
tively simple motions, such as an oscillating airfoil, 
yet still be general enough to handle any arbitrary, 
complex motion. The specification allows for pre- 
scribed motions (either analytically or through a 
discrete table look-up), unconstrained 6-degree-of- 
freedom (6-DOF) rigid-body motion, as well as con- 
strained (1-DOF, 2-DOF, -•■) motion. Finally, it 
can describe what is referred to here as “controlled 
6-DOF motion”, as in a guided missile or aircraft 
flying under a control system. Detailed examples 
for describing a prescribed analytic motion and a 
constrained 6-DOF motion are presented in this pa- 
per. 

One of the primary goals for the current devel- 
opment was that it support extensibility, so that it 
can be used in currently unanticipated roles. The 
major means to meet this goal was to provide a 
flexible structure that can be augmented in an al- 
most arbitrary manner. The specification is inde- 
pendent of any application type, such as structured 
grid technology, or a particular CAD implementa- 
tion. The API was also designed to be independent 
of any application. Rather than provide a com- 
plex API which attempts to be “all things for all 
people” (and usually fails), the API is kept very 
simple, and it is the responsibility of the applica- 
tion programmer to build the data structures, or 
complicated interfaces, which are apropos for their 
particular application. For example, the current 
GMP implementation is integrated within several 
distinct applications[9-ll]. Each of these applica- 
tions provides a layer of “middleware” between the 
interface datatypes, and the more complex (special- 
ized) data structures used within each application 
code (cf. Fig. 1). 


3 Typographical 
Conventions 

As the current work is essentially a description of 
a set of datatypes, a consistent font system is used 
as an aid. All datatypes from the GMP are capital- 
ized and displayed in sans serif font, e.g. Configura- 
tion. Most of the types have names which connote 
their intention, and hence are often used as a nor- 
mal part of a sentence. Hierarchical datatypes are 
displayed with an indented list, such as 

• Configuration 

— Component 

where in this case Configuration is composed of 
lower-level Components. Types are provided with 
a parenthetical argument which describes whether 
the type is required, optional, etc. Types which are 
composed of base types, such as strings, scalars, 
etc. are shown with a bracketed argument contain- 
ing the base types, for example Name [string] (re- 
quired). Arguments which are typed in directly are 
shown in fixed-width font as in 10 . 0*sin(2*pi*t) . 

4 Analytic Function Parser 

The interface specification relies heavily upon a 
generic function parser which is capable of pars- 
ing and interpreting arbitrary analytic functions. 
These analytic functions can take an arbitrary 
number of arguments. The parser understands the 
common mathematical operators and precedence 
rules, such as “(), common con- 

stants such as 7T, and most commonly used func- 
tions such as “abs, log, sin, sqrt, tanh, For 

example, pitch rate {ct{t) — 10.0 sin (27rt)) for an os- 
cillating airfoil is expressed as 10 . 0*sin(2*pi*t) , 
and can be evaluated at run-time by providing an 
appropriate scalar value to substitute for the vari- 
able t. This substitution mechanism is provided by 
the function parser API. Within the GMP, an an- 
alytic function which takes no arguments replaces 
the role of a scalar value, i.e. a single scalar, or 
numeric value, is not an explicit type. In this man- 
ner, it is possible to use variables and constants 
which are appropriate to the problem, making the 
interface easier to specify. For instance, an angle 
of rotation can be specified as pi/4, as opposed to 
0 . 7854, and the result will be evaluated at run-time 
by the application using the API for the function 
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parser*. In the current specification, a nomencla- 
ture is adopted to describe the analytic function 
datatype, and optionally the arguments which are 
expected. All numeric fields are specified as an ar- 
bitrary function which takes no arguments, f{). If 
an analytic function datatype is expected to take 
an argument of time in the interface, it will be de- 
scribed using f(t). A vector of 3 numeric fields, 
such as is used to describe a position, is specified 
as vector: f{). 

5 Configuration 
Specification 

The complete geometry which is being simulated 
is referred to here as a Configuration. Before a mo- 
tion can be specified, it is necessary to describe 
the Configuration, so that a user can simply de- 
scribe the motion of “the left rotor’ , as is intu- 
itive, rather than being forced to refer to some 
application-specific geometry description. Instead 
of tightly coupling the Configuration information 
with a motion specification, the means of specifying 
a Configuration and the means of specifying its mo- 
tion are separated. The motion specification is then 
built by referring to the Configuration. This allows 
different motions to easily refer to the same Con- 
figuration, as well as provides the ability to build 
separate tools which extend the Configuration. 

Within GMP, the Configuration description is 
stored in an XML file typically named Config.xnil. 
An example Configuration file for the V-22 tilt-rotoi 
is included in Appendix A. A typical Configuration 
is often made up of lower- level pieces, referred to 
here as Components. A simplified representation 
of the V-22 tilt- rotor geometry is shown in Fig. 2, 
with the different Components highlighted by color. 
The V-22 is made up of many Components, such as 
the fuselage, wing, empennage, rotors, etc. Many 
of these Components can also be further broken into 
smaller pieces, for example the rotors can be bro- 
ken down into a nacelle, hub, and blades. This 
suggests that the Configuration is composed of a 
hierarchy, or tree, of Components. One possible hi- 
erarchy structure for the V-22 is shown schemati- 
cally in Fig. 2. Notice also that this hierarchy is not 
unique, for example the rotors might be considered 
as a lower-level Component of the wing, or on the 
same level as the wing. These different hierarchies 

*It is still possible to use a simple scalar value, and it will 
evaluate to itself at run-time. 




Figure 2: Example Configuration hierarchy for the V-22 tilt- 

rotor. Component types are specified by color and text. Solid 

lines represent a parent-child relationship, and dashed lines 
represent a source-clone relationship. 

can become important when specifying the relative 
motion, however, as will be described in the next 
section. 

While the abstract hierarchy description of a 
Configuration is helpful, at some level it must be 
associated with the actual geometry that is to be 
manipulated. This is accomplished by requiring 
that each Component specify its Type, and option- 
ally include some type-dependent Data. In order to 
promote flexibility within the Configuration specifi- 
cation, each type of Component is considered equal, 
and can be utilized anywhere within the Configura- 
tion hierarchy. Further, the Component types form 
an open-ended list which can be extended by future 
applications as needed. In other words, it is up to 
the external applications to determine which type 
of Components they can work with and understand, 
not the specification, and similarly for the optional 
type-dependent Data. A small number of Compo- 
nent types have been developed in implementing 
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the GMP within the three application codes from 
Refs. [9-11]. The tree-diagram of Fig. 2 includes 
a label with the different Component types. These 
types are briefly described as 

• St rue: A set of structured grid (possibly over- 
lapping) surface patches 

• tri: A surface triangulation 

• container: An agglomeration of lower-level 
Components 

• clone: An duplicate of another (non-clone) 
Component 

A Component of the Configuration hierarchy has 
the following complete list of attributes: 

• Component: 

- Name [string] (required) 

- Type [string] (required) 

- Parent [string] (optional) 

- Data [arbitrary] (optional) 

- Source [string] (optional) 

— Transforms (optional) 

* Translate (optional) 

• Displacement [vector: f()] (re- 

quired) 

+ Rotate (optional) 

• Center [vector; f()] (required) 

. Axis [vector: f()] (required) 

• Angle [f()] (required) 

♦ Mirror [x\y\z] (optional) 

The Parent attribute is used to specify the tree 
structure of the Configuration. The motion of a 
Component is usually specified relative to its Parent. 
Root nodes of the tree have no parents (the inter- 
pretation being that the inertial reference frame is 
the parent for motion), and multiple root nodes are 
allowed. The Source tag specifies optional informa- 
tion, such as a filename or link, for the Component, 
so that the Configuration can potentially be built 
from a library of stored Components. The Trans- 
forms tag is used if the Component is to be trans- 
lated, rotated, or mirrored into position within the 
Configuration, and is made up of sub- types for spec- 
ifying the actual transformations. All coordinates 
used in the transformation are specified in the orig- 
inal, untransformed (natural) coordinate system of 


the appropriate geometry. The clone Type can 
represent an exact duplicate, although in most in- 
stances the original is copied and then Transformed 
to a new position. For example, the cloned Com- 
ponent can be Mirrored about the x, y, or 2 = 0 for 
Configurations with lateral symmetry. Similarly, a 
single turbine blade can be cloned and Rotated to 
form a set of blades around a hub. In this manner 
errors due to duplication are reduced, and a com- 
mon set of methods can easily be extended to an 
arbitrary number of Components. 

6 Motion Specification 

Each motion specification refers to the Configu- 
ration description outlined in the previous section. 
The specific Components which are in motion are 
referred to by their Name attribute. The motion, 
or sequence of motions, is described by what is re- 
ferred to as a Scenario, and is specified in an XML 
file named Scenario. xml. Scenarios are parameter- 
ized by time (t), starting at t = 0, with the units 
of time dependent upon the application. A Sce- 
nario is characterized by a number of actions, each 
occurring at a specific time, and for a specific dura- 
tion. Currently, two types of actions can be spec- 
ified; Prescribed motions, and Aero6DOF motions. 
These two types of motions are considered as dis- 
tinct types as there is little commonality between 
them. 

6.1 Prescribed Motion 

The Prescribed motion can be specified as an ar- 
bitrary analytic function of time, or through a dis- 
crete table look-up. The analytic functions of time 
are parsed and evaluated by the stand-alone func- 
tion parser described in Sec. 4. The time is inter- 
preted as relative to the Start time of the current 
Prescribed motion, and a substitution of this cur- 
rent relative time is performed whenever the an- 
alytic functions are evaluated. This allows a Pre- 
scribed motion to be used multiple times within the 
same Scenario without modification. In order to 
specify the motion, either the position of a Com- 
ponent must be specified, or its velocity and ini- 
tial position, though both position and velocity are 
usually needed by most CFD flow solvers. Since 
the initial position is available from the description 
of the Configuration, and it is easier to numerically 
integrate a function accurately than it is to differ- 
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entiate, the analytic motion is Prescribed by pro- 
viding the translational and angular velocities over 
the time period. The exception to this is the table 
look-up mode of operation, where the flexibility to 
specify only the position is allowed. 

Motions are usually Prescribed relative to the 
parent of the Component within the Configuration 
hierarchy, and this is the default behavior. Op- 
tions are discussed with the hovering bee example 
in Sec. 6.3. The motion is specified in the initial 
coordinate system of the input geometry (after any 
required Transforms have been applied within the 
Configuration specification). 

Prescribed motions have the following required 
and optional attributes: 

• Prescribed 

- Component [string] (required) 

“ Start [f()] (required) 

- Duration [f()j (optional) 

- InitialPositicn (optional) 

* Translate (optional) 

• Displacement [vector; f()) (re- 
quired) 

* Rotate (optional) 

• Center [vector: f()j (required) 

• Axis [vector: f()| (required) 

• Angle [f()j (required) 

* Mirror [x\y\z] (optional) 

- Translate (optional) 

* Velocity [vector: f()j (required) 

* Frame [string] (optional) 

- Rotate (optional) 

+ Center [vector: f()| (required) 

+ Axis [vector: f()j (required) 

+ Speed [f()j (required) 

* Frame [string] (optional) 

Start and Duration refer to the starting time and 
duration of the action. If the Duration is not speci- 
fied the action is considered to be continued indefi- 
nitely. Prescribed motions are allowed to overlap in 
time intervals, and are ordered by their Start times. 
Initial Position allows the orientation of the Com- 
ponents within a dynamic simulation to be trans- 
formed after a Configuration has been “built”. This 
allows a general Configuration to be described, and 


then specialized if necessary for a dynamic simu- 
lation, i.e. it further decouples the Configuration 
and motion specification. The time level t = 0 is 
assumed to refer to the position of the body after 
the (optional) InitialPosition transforms have been 
applied. The Translate and Rotate commands spec- 
ify the translational velocity of the center of mass 
of the component, and the rotation rate about an 
arbitrary axis through the center of rotation respec- 
tively. These commands are specified in the coor- 
dinates of the axis system specified by the Frame 
type. Choices for Frame are body or parent, with 
the default being parent. Multiple Translate and 
Rotate commands can be combined within a single 
Prescribed action, and are applied in the order they 
are specified within the XML file. 

6.2 V-22 Example 

The first example Prescribed motion is a specifi- 
cation of the V-22 tilt-rotor where the V-22 rotors 
are transitioning from the vertical to horizontal po- 
sitions (by rotating about a wing chord line), and 
the blades are continuously rotating about an axis 
through the rotor hub (cf. Fig. 3). The left and 
right sets of blades are counter-rotating. The com- 
plete Scenario specification is included in Appendix 
A. All of these motions are relative to their Par- 
ent in the Configuration hierarchy. Note that since 
the rotor blades counter-rotate, i.e. move differ- 
ently relative to their parent in the Configuration 
hierarchy, it is not possible to simply clone one of 
the rotors, even though the geometries involved are 
simply mirror images, as this would imply that all 
of their sub- Components moved in exactly the same 
manner. The Configuration is thus both an abstract 
topology as well as a concrete means of manipulat- 
ing geometry. 

6.3 Hovering Bee Example 

The second example Prescribed motion is of a bee 
flapping its wings to hover (cf. Figs. 4 and 5), and 
is also included in Appendix B. The Configuration 
for the bee is a more complex example, including 
cloned Components and several levels of hierarchy. 
The analytic formulation for the wing motion is 
based on the observations of Ellington [12]. As op- 
posed to the V-22 tilt-rotor, where the compound 
motion is a superposition of the motion of various 
Components relative to their Parents, here the com- 
pound motion is of a single Component performing 
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(c) time = 0.70 



(d) time = 1.05 

Figure 3: Snapshots of V-22 rotors transitioning from the 
vertical to horizontal positions, while the blades continu- 
ously rotate about the rotor hub. The GMP XML specifi- 
cation for this motion is included in Appendix A. 


ail ordered series of actions. In the V-22 example, 
all of the motions are specified in the parent co- 
ordinate frame, which is the default frame. When 
working with a complex motion of a single compo- 
nent, it is desirable to specify actions relative to the 
parent or relative to the continually moving body 
frame. In the flapping wing example, the motion of 
the wing is specified as a stroke and flapping about 
axes in the parent system, and a pitch about a wing 
span axis. Setting up this (relatively) complicated 
motion with the aid of the OVERGRID GUI and 
current motion specification infrastructure required 
approximately 15 min. 

6.4 6-DOF Motion 

Along with Prescribed motions, CFD applica- 
tions often simulate 6-DOF motions where the 
rigid body is free to move under the influence of 
aerodynamic loads. With the exception of Start 
and Duration times, the specification of Prescribed 
and Aero6DOF motions have little in common, and 
hence are treated as separate types. A component 
cannot be specified as having both Prescribed and 
Aero6DOF motions overlapping in time. Once a 
Component has been specified to have an Aero6DOF 
motion, it is no longer considered to be a child 
of its Parent (if it had one), and becomes a root 
node, i.e. the Configuration specification becomes 
dynamic when Aero6DOF motions are considered. 

Aero6DOF motions contain the same Name, 
Start, Duration, and InitialPosition types as Pre- 
scribed motions, but also contain sub-types for In- 
ertialProperties, AppliedLoads, Constraints, and Con- 
trollers. These latter are treated as sub-types of an 
Aero6DOF type, as opposed to types of their own, 
in order to make them more general. For exam- 
ple, if the AppliedLoad was a type then it would 
need to refer to the Aero6DOF motion it applied 
to in some manner. The AppliedLoad type would 
then need to be modified each time it was applied 
to a different Component. By making AppliedLoad 
a sub-type, it is implicit which Component it ap- 
plies to, and it is also possible to use the same Ap- 
pliedLoad with multiple Components without mod- 
ification, For example, if a store ejector is mod- 
eled, this ejector can be tested with different store 
geometries simply by referencing the appropriate 
XML code within the specification. Similar argu- 
ments apply to Constraints and Controllers, as Ap- 
pliedLoad. AppliedLoad, Constraints, and Controllers 
can be thought of as ‘‘modifiers” for the Aero6DOF 
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Figure 4: Configuration hierarchy for the bee in Fig. 5. Component types are specified 

represent a parent-child relationship, and dashed lines represent a source-clone relationship, Ihe GMP XML specification 
for this Configuration is included in Appendix B. 



(b) Upstroke (left to right) 


Figure 5: Snapshots of a bee flapping its wings in hover. The Configuration hierarchy for this example is in Fig. 4, and 
the GMP XML specification for this motion is included in Appendix B. 


type. In this manner it is possible to build a library 
of ejector models, feedback systems, etc,, which can 
then be used within different simulations without 
modification. 

The complete type map for an Aero6DOF motion 
is 

• Aero6DOF 

- Component [string] (required) 

- Start [f{)] (required) 

- Duration [f()j (optional) 

- InitialPosition (optional) 


* Translate (optional) 

■ Displacement [vector: f()j (re- 

quired) 

* Rotate (optional) 

■ Center [vector: f()| (required) 

. Axis [vector: f()] (required) 

• Angle [f()] (required) 

* Mirror \x\y\z] (optional) 

- InertialProperties (required) 

* Mass [f(t)j (required) 

* CenterOfMass [vector: f(t)j (required) 
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* PrincipalMomentsOflnertia [vector; 
f(t)] (required) 

* PrincipalAxesOrientation (required) 

• Axis [vector: f()] (required) 

• Angle [f()] (required) 

- AppliedLoads (optional) 

* Start [f()] (required) 

* Duration[f()] (optional) 

+ Frame [string] (required) 

* Force [vector: f(t)] (optional) 

* Moment [vector: f(t)] (optional) 

— Constraint (optional) 

* Start [f()j (required) 

* Duration [f()| (optional) 

* Translate [vector: f(t)] (optional) 

* Rotate [vector: f(t)j (optional) 

“ Controller (optional) 

The initial translational and rotational velocities 
are either zero if no Prescribed motions were in ef- 
fect previously, or are equal to the Prescribed val- 
ues. it is assumed the origin of the PrincipalAxes 
corresponds to the CenterOfMass location at the be- 
ginning of the Aero6DOF motion. The InertialProp- 
erties are allowed to be general functions of time, 
as is necessary to model a rocket burning fuel, or a 
satellite deploying an arm. it is the responsibility 
of the application to implement a suitable model 
for solving the 6-DOF equations under these con- 
ditions. 

The AppliedLoads can be specified in 3 different 
coordinate frames; body, parent, and inertial. 
An example of a parent frame would be a pylon 
ejector force for a store separation. A constant 
thrust could be modeled using an AppliedLoad in 
the body frame. Constraints on the other hand are 
always assumed to be relative to the parent frame. 
The Constraint is specified as either a Translate con- 
straint, Rotate constraint, or both. The numerical 
inputs are bounded by 0 and 1, with 1 correspond- 
ing to unconstrained motion and 0 for no allowed 
motion relative to the parent system. The three 
components of the Constraint vector are the x^y,z 
components of translation or rotation. Arbitrary 
functions of time can be specified for the Constraints 
and AppliedLoads. Controller types are specified as 
modifiers to the Aero6DOF motion, however they 
are currently left vague until more experience is 
gained with controlled, 6-DOF motions. 


6.5 Space Shuttle Example 

An example specification for an Aero6DOF mo- 
tion is the Space Shuttle ejecting its two Solid 
Rocket Boosters (SRB) after burnout (cf. Fig. 6). 
The SRBs are free to move under the influence 
of aerodynamic forces, and an additional external 
ejector force is applied over the first time unit. 



(a) Initial position 



Figure 6; Snapshots of Space Shuttle SRBs releasing after 
burnout. The GMP XML specification for this Configurstion 
and its motion is included in Appendix C. 


7 Implementation 

The current work specifies a set of datatypes and 
rules for their interaction, without enforcing any 
particular implementation model. The implemen- 
tation is left to the particular applications, as dis- 
cussed in Sec. 2. In fact, it is assumed that the 
applications will only implement a subset of the 
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Figure 7: Required transformations to place a moving Component at current time level. The 

from the top down each vertical arrow. Horizontal arrows represent transformations that are composed o p P _ 

Lch Prescribed action is an accumulation of the individual commands, in both the parent and body systems^ The s.m.la 
frrnsfmmations from each Component in the hierarchy is applied to each of its children. This is done after each Component 
has been initialized in the Configuration, and placed in its InitialPosition by the Scenario. 


specification. For example, the middleware for the 
Cartesian package[9] is customized for unstructured 
triangulated surfaces, while the overset solver[10] is 
customized for structured surface patches.* Fur- 
ther, applications may choose to ignore compli- 
cated or seldom-used features. For example, im- 
plementing the clone Component type adds a layer 
of complexity for the implementation and may not 
be necessary for all environments. Similarly, imple- 
menting a 6-DOF model which can handle variable 
ma 5 S systems may not be necessary, etc. These de- 
cisions are left to the application environment. 

A discussion of some features of the implementa- 
tion used in [9—1 1] is presented in order to pro- 
vide further understanding. One basic require- 
ment of any implementation is the ability to eas- 
ily transform between the body and inertial coor- 
dinate systems. The aforementioned applications 
use homogeneous transformation matrices (cf. van 
Arsdale[13]) to represent the transforms, which are 
capable of uniformly representing translations, ro- 
tations, mirroring, dilation, etc. The net effect of 
any Transform or Prescribed command is then a cu- 
mulative matrix product of the individual transfor- 
mations, applied in order (cf. Fig. 7). When ap- 
plying the Prescribed commands, a further step is 
necessary in order to account for the motion of the 

*Both CFD solvers can understand the same motion Sce- 
narios however, as long as the Configurations are similar. 


Configuration hierarchy, as any transformation of 
the Parent component affects the position of the 
child. The Prescribed command processing is han- 
dled in two stages. First, a homogeneous transfor- 
mation matrix is constructed by considering each 
Component in isolation, then the matrices from the 
Configuration hierarchy are applied by traversing 
the Configuration tree from top to bottom. The 
transformations required to place a body in posi- 
tion for a Prescribed command at an arbitrary time 
level are shown schematically Fig. 7. 


8 Summary and 
Future Work 

The GMP package implements a low-level spec- 
ification for describing geometric configurations 
and their arbitrary rigid-body motions. Higher- 
level applications, such as visualization tools, au- 
tomated post-processing environments, and CFD 
flow solvers, are built on top of the low-level pro- 
tocol. The specification is intended for either in- 
teractive use through a GUI, or modification by 
application control scripts as part of an automated 
process. The protocol reduces the information re- 
quired for describing and manipulating geometry to 
an XML file which is portable between different op- 
erating systems and different application programs. 





This single repository for the specification reduces 
errors due to duplication, and also provides a self- 
documenting capability. 

As more experience is gained with the GMP 
specification it will continue to evolve. The flex- 
ibility to handle this evolution has been incorpo- 
rated into the specification wherever possible. The 
stand-alone Configuration specification has many 
potential uses beyond providing a means to specify 
rigid-body motions. Some application areas which 
are currently in development include: integrating 
the Configuration specification with post-processing 
tools for calculating integrated forces and moments, 
providing a means for specifying a Configuration 
‘‘space” (ConfigSpace) for use when generating a 
matrix of static simulations with different geomet- 
ric settings, and extending the Configuration to in- 
clude non-rigid bodies. Deformable bodies are re- 
quired in order to morph geometry within a geo- 
metric optimization package or perform aeroelastic 
simulations. These types of low-level descriptions 
are required in order to build reliable automated 
tools for CFD simulations. 

Within the current specification, the Controller 
modifier for Aero6D0F motions has been left inten- 
tionally sparse until more experience is gained with 
controlled simulations. One outstanding item is the 
ability to repeatedly execute a command, or series 
of commands, optionally in a loop. This ability is 
currently being added and tested within the speci- 
fication by generalizing the Start time, and will be 
supported in the future. 
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Appendix 


A V-22 Example 
Specification 


This specifies a possible Component hierarchy for 
the V-22 tilt-rotor shown in Fig. 3. 


<Con f igu ra t i on> 

<Cong)oncnt iuidb* '’S tarboard Nacelle" p«r«Qt- ’Nacelles" 

Typ«-"3truc ■■> 

<Data> Grid Liat-82-97 </Data> 

</Component> 

<Component Baw'Port Nacelle” p*r«Dt* ’’Nacelles Typ«="struc > 
<Data> Grid Liat”66-81 </Data> 

</Convponen't> 

<Cowponent "Nacelles" p«rent-"Main Body" Typ«= ’ container ”/> 

cComponent Maw- “Main Body" Type- " struc "> 

<Data> Grid Liat— 1-65 </Data> 

< /Componen <:> 

<Component Hajn*-" Starboard Blades" Parent- ’ Starboard Nacelle” 
Type-"struc‘> 

<Data> Grid Liat-107-115 </Data> 

< /C onrponen t> 

<CoiT(>onent N-m- ^"Port Blades" Parent="Port Nacelle” 

Type- "St rue "> 

<Data> Grid* List-98- 106 </Data> 

</Component> 

< /Conf igurat ion> 


<Cofnponont Wing- r»r»nt-"Thor«*- Typ«-'trJ-> 

<0»t»> facB Lab«l-9, 10 

</CoB!pai\»rt> 

<cortipon»nt Wing" r.r-ot-'thorax' r,p.- “clone “j 

<Tr»n iifoni>> 

<Mlrror Hene-'i''/> 

</Tran*torm> 

<0et«> Original - ‘Left King- </i>et»> 

</Coeprinent> 

<compon.nt Legs" p.r.nt-'tegs “ Type-'trj“> 

<5at«> Pace Lebol-l, i, 5 
</CQinpon*nt> 

<Compon*nt »««e- Bigtit I.eg»- re rent-'l^eg* ' Iype-”c lone“> 
<Tr«ns f orm> 

<Mirror plane- "y"/> 

</Tr«n« fomi> 

<Dat«> original “ 'Left Logs- </o»tm> 

</Compnnent> 




*»--Laqs' Pnrent-'Thorax" Type- “container's 


<Coniponent »e— e-“Laft Antennae" Parent- "He 
<Data> Pace Label-1 </n«ta> 
</Co»ponent> 

<Component »ajee- “B igl^t Antennae' Parent-"* 

<XranafDr7Ti> 

orirror plane- ''i~ /> 

</TranRforn> 

<Data> Original - “Left Antennae" </Oe» 


■ Type«"trl“> 

race Label-7 </n«t«> 

</Component> 

<Co«ponent paM-'Sight Eye* Perent-'Mead' Type-'olone' 
<Xranaf Dr7»> 

cMirror Plene-“y“/> 

</Tran*f onx> 

<0ata> Original - 'Left Eye' </Oate> 

</Coi»ponent> 

<Component M.»a-''Haad- Perent- “Body" Type--tri'> 
<Data> pace Label-6 </D«ta> 

< /Coupon* nt > 

<cotriponent B««e- “Thorax " Parent- 'Body “ Xype-"tri*> 
<[>ata> pace Label-1 </Data> 

</Coinponent> 

<CDraponent pn«n-"Abdoraen- Ferent-'Body ' type-'trl'> 
</Coffipon« nt > 

<Component pn^-'flody" Peceat-'Bug" Type-'container '> 
</CompDTl«nt> 

<CD-pon«nt p***-*auq“ iyp«- "container “> 


This specifies the motion of the V-22 tilt-rotor 
Configuration show in Fig. 3. The rotors transition 
from the vertical to horizontal positions, and the 
blades are continuously rotating about the rotor 
hub. The left and right sets of blades are counter- 
rotating. Figure 3 contains snapshots of the motion 
at 4 instances during the transition of the rotors. 


</ConfL5-uratiort> 

The following is a motion specification for the 
hovering bee shown in Fig, 5 expressed in XML 
syntax. The compound motion of the wings 
is an ordered series of rotations; two about 
body axes and one about a wing chord line. 


<Scenario> 

<Prescrib«d Cowponent- "Nacelles ” Start-" 0" Duration- ” 1 ’’ > 
<Rotate Canter-’’ 0.86775, 0, 0.3742” *xia-’0, -1, 0" 
Spaed-” 0.5*pi" /> 

</Preacrib«d> 


<Prescrib«d Component- "Star board Blades Start- 0 > 

<Rotate Center- "0.9036 14, 0.602761, 0.662562" Axia-’ 0, 
Speed-" 2.0 * pi” /> 

</Prescribed> 


0 , 1 “ 


<preacribed Component- " Port Blades" Start- 0 > 

<Rotate Center-'*0.903614, -0,602761, 0,662562" 
Speed-'* 2.0 * pi" /> 

< /Prescribed^ 


Axia-’’0, 


0 , - 1 ” 


</Scenario> 


B 


Hovering Bee Example 
Specification 


The following is a Configuration specification for 
the bee geometry shown in Fig. 4 expressed in XML 
syntax: 


<5cen« 

<Pr«flK 


;-"Left Ming" tt»rt-‘0.2S" Dur«tioo-‘0. 50" i 
48, 13.3" A*i«-”0, -0,999343, 0.0362456” 
fraea- ’ body"/> 


;rib-d Co«pon*nt-"Left Hing" it.rt-'ll* ! 

.t«t« cin^- 0, -48, 13.3" -0.999343, 0.0362456 


<Pre!ierik«d CoHporwnt-' Lef t Wing’ lt»rt-'0" 
<Rotat« C«ntar-”0, -4 7, 0’ <>, -• 

«p-ed-'pi/3-25 * pi *com<pi‘t + 4 
<Rotate C«ntar-'0, 0, 0" 0, 

gp««d-'0.25*pi*cos(pi*t) ’/> 

</Pr»Bcrib*d> 


n(pi/10.0))*/> 




."Right Wing” •t«rt-‘0.25- I>ur»tlon-*£>.50" 
48, 13.3" 0.999343, 0.0362456' 

rraae-’body" /> 


</PrcBcribed> 

<Pr«Bcrib«J Ca*po«nt-”Right Wing" O^tion-“0.50" > 

<Rot»te C«ntIr-”0, <«. 13- 3" Axii-'O, 0.999343, 0.0362456 

gp«^-”-pi* Pr«»*-’'body“/> 

</Pr«Bcrib»d> 

<Prcscribe<J co«pon«nt-"Right Wing" start- C > 

<Rotate Cant«r-'Q, <2, 0’ fciia-“0, 0. 1“ 

gp*^-"pi/3,25 * pi *co»(pl*t + *9in{pi/10.0>) /> 
Ototata Cant«r-'0, 0, 0* Axla-'i. 0, 0" 
gp*«d-"-0. 25*pi*ooa(pi*t J •/> 

</Pra»criba<l> 

<Pr«*cribed Caag*on«nt“"Bcdy" Start"" 0“ > 

<Rotata Cant«r-'0, 0, 0* JUia-'O. 1. 0' 

ip*«d“"pi*( pi/24. 0)*coB(pi»t)" /> 

</Preact-i b«d> 

<PreBcrib*d Ccaaponant-'Leq*" Start"' 0" > 

<Rotata Cantar-"0, 0, 0“ A*ia"‘0, I, O' 

tp*«l-'pi*(pi/36.0)*eo*(pi»t)- /> 

</Pre»crib«d> 

< /Scenario 
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C Space Shuttle Example 
Specification 

The following is a Configuration spec- 
ification for the Space Shuttle shown 
in Fig. 6 expressed in XML syntax. 




<Conf iquration jUigl#Ualt- ' radian ‘> 


<Coiopoiiciit NaBB^'Orbitar ' Typ*“ ' strac "> 

<Dat«> Grid tiat- 6 , 32 , <7-57, 59-61, <3-06,90-92. 94, 96-105 
</Compoocnt> 


</Da t«> 


<Conipon«nt SRB’ P*r*nt- " E xtarna 1 Tan)t* Typ«-"»truc' 

<Oata> Grid Liat- 16 - 21 , 107 </Dat«> 

</Component.> 


<Co»ponent Hw'Right SRB' pa real- “ Ext-erna 1 TanX' rypa-' atruc "> 
<Dat.a> Grid Liat" 22-2 7 , 106 </Dnta> 

</ConpoDcnt> 


<Coinponent MaBe-’Extarnal Tank* Parant- "Orbiter ” Typ«-‘*true 
<D«ta> Grid Liat- 1 - 5 , 7 - 15 , 28 - 31 , 33-46 </Data> 

</Co»poncn t> 


</Conf 




The 

following 

is the Aero6D0F See- 

nario 

for the 

Space Shuttle SRB re- 

lease 

expressed 

in XML syntax: 

.• rn.t.Tvir 

<Sca nario 

.r‘c.-' • r.-. 1 1 : o ‘rVT/- :-f -r ■ r?- 1 j 

Soparjitio 

n- OcaTlty-" 0 . 0 , 0 . 0 , - 32 . 2 " toglaIJnit- DEG-> 

<Aaro 6 do< 

CoapoMnt^'*Ij&Ct 5 Rfi'‘ 
■t»rt-“ 0 . 0 ‘> 



tf,,, far the .tues if inifil ly the .-..ti. • 

< In«rt. lAl^z’op«irki*ii 

. 4 r “0-25, 1,642" 

Prlnoipalitoai*BtaOfIn*rtl«-“ 422 , 40711 , 40711 ”> 

<PrincipalAx«»Ori*nt«tion Axi»-‘ 0 . 0 , 0 , 0 . 1 . O' An^l*- " 0 . 0 -/> 

</ Inart ia lProp«rt imn> 

<Af>pIi«dLoad atart-'O-O- Ousatioa' '1 . O' fr»»a- •parent' rorea-'OO, - 200 EJ, O.O" /> 
</(iaro6dof > 

<Aaro 6 dof Caapoaant-' Right SRB" 

■tart-' 0 . 0 -> 


<; — tfr,? center for the ptinci/vif .txrs is j.apJrcrtiy the c.n, - 
<I M rt ia 1 Pr opart ias 
Ifcaa-'lSDEi' 

CantarOfMBas-'0.4, 0.25, 1.S42" 

PrlnaipalMf ■ntaOttBarti«-~422 , 40711, 4071 1"> 

<PrincipalAxaaOrlantation A»i«-‘'a, 0 , 0 . 0 , 1 . 0 ' Xn^la- " 0 . 0 '/> 

</ tnart i« LProp«rt i«»> 

<R.ppliadLoad «tact-'0-0" Duration- ' 1 .O' fraaa- ' parent' Poroa-’’0.O, 200E3. 0.0' /> 


</Aaro 6 dof> 

</Scaeario> 
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